Data communication networks may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to pass data to one another. These devices will be referred to herein as “network elements.” Data is communicated through the data communication network by passing protocol data units, such as data frames, packets, cells, or segments, between the network elements by utilizing one or more communication links. A particular protocol data unit may be handled by multiple network elements and cross multiple communication links as it travels between its source and its destination over the network.
The various network elements on the communication network communicate with each other using predefined sets of rules, referred to herein as protocols. Different protocols are used to govern different aspects of the communication, such as how signals should be formed for transmission between network elements, various aspects of what the protocol data units should look like, how packets should be handled or routed through the network by the network elements, and how information associated with routing information should be exchanged between the network elements.
A Virtual Private Network (VPN) may be formed by securing communications between two or more networks or network elements to form a VPN connection, such as by encrypting or encapsulating transmissions between the networks or network elements. Using VPN connections enables information to be exchanged securely between geographically dispersed sites without obtaining dedicated resources through the network.
There are several commonly utilized methods of establishing VPN connections on a network. For example, VPNs may be established by customers through the deployment of network elements configured with VPN software. Another way of establishing VPNs is to configure the VPN at the Provider Edge (PE) network elements to allow the service provider to provision VPN services on behalf of the customer. The service provider also provisions the tunnels between provider edge (PE) elements which are shared by many VPN sites attached to PE. The tunnels traverse through provider (P) network elements which are completely unaware of presence of any VPN. One common way to do this is described in Internet Engineering Task Force (IETF) Request For Comments (RFC) 2547, the content of which is hereby incorporated herein by reference. RFC 2547 describes a Layer 3 VPN architecture in which MultiProtocol Label Switching (MPLS)-based tunnels are used to forward VPN packets over the provider network backbone. Another common way to do this is described in IETF Internet Draft (ID) entitled “Framework for Layer 2 Virtual Private Networks (L2VPNs), by Eric Rosen, which allows for the creation of Layer 2 VPNs (L2VPNs), the content of which is hereby incorporated herein by reference. Once established, the provider tunnels may be used to pass data between the VPN sites attached to the PE elements on either end of the VPN connection.
FIG. 1 illustrates a simplified example of a network topology 10. In FIG. 1, traffic from a Customer Edge (CE) network element 12 associated with a first VPN site 14 is output to a Provider Edge (PE) network element 16. The PE 16 may be a separate device/machine on the network or, alternatively, may be instantiated as a process on another network element. MPLS tunnels 18A and 18B are determined by the PE network element 16 and implemented on the network 20 in a conventional manner. The MPLS tunnels terminate at a second PE network element 16 which interfaces a CE network element 12 associated with a second VPN site 14. Numerous protocols like RSVP-TE or LDP may be used to establish the MPLS tunnels on the network in a conventional manner.
When an end-point of an MPLS tunnel fails, such as when a card or port in the PE network element hosting the MPLS tunnel fails, it is necessary to switch the VPN traffic going over that tunnel to another MPLS tunnel between the same pair of PE elements. Where only one MPLS tunnel has been established between the end points, a new MPLS tunnel will need to be determined. Generally, however, to enable rapid failover of a VPN traffic between MPLS tunnels, multiple MPLS tunnels are set up between pairs of PE elements so that upon failure of one MPLS tunnel (e.g. MPLS tunnel 18A), the traffic may be quickly switched to another MPLS tunnel (e.g. MPLS tunnel 18B). Selection between available MPLS tunnels occurs via a tunnel selection algorithm.
To enable traffic to be transferred at very high data rates, network elements are constructed conventionally with a control plane configured to handle signaling, configuration, and other control information, and a forwarding plane configured to forward data based on lookup tables set in the forwarding plane by the control plane. For example, establishment of MPLS tunnels and mapping of a VPN traffic over an MPLS tunnel or a group of MPLS tunnels is handled by the control plane. MPLS tunnel information for the selected VPN connection is then passed from the control plane to the forwarding plane, which uses that information to program the processors and circuitry forming the forwarding plane to enable it to forward packets associated with the VPN onto the selected MPLS tunnel on the network.
When a port or card hosting the MPLS tunnel fails, the control plane needs to detect the failure, choose another MPLS tunnel using a tunnel selection algorithm, and program the forwarding plane with new MPLS tunnel information for the affected VPN connections. Since a given port or card in a PE network element may handle tens of thousands of VPNs, determining new MPLS tunnels for those VPNs and communicating that information from the control plane to the forwarding plane may take between hundreds of milliseconds to well over a second. While this may be an acceptable rate for particular types of traffic, the failover rate must be reduced to the order of 50 milliseconds if the VPN connections are to be able to be used to carry time-sensitive traffic, such as voice, and video traffic.
There have been attempts to reduce the failover rate using mechanisms included in the protocols already in use on the network. RSVP-TE is the most commonly used protocol to establish MPLS tunnels in an MPLS network. In RSVP-TE, one mechanism that may be used to reduce the failover rate is to reduce an interval associated with optional RSVP hello messages used to check integrity of the RSVP neighbor for the tunnel to as little as 5 ms, to thereby provide fast notification of a failed link or card. However, this solution is very processor intensive, requiring the generation and transmission of 200 hello messages per RSVP neighbor per second. Additionally, while this provides fast notification of a problem, it does not accelerate the manner in which the network element handles the problem once notified. Thus, where there are thousands or tens of thousands of VPN connections affected, the control plane may be incapable of reprogramming the forwarding plane with new MPLS tunnel information for the affected VPNs within a 50 ms failover period, even if it is notified of the problem in a timely manner.